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ABSTRACT 


An online systems engineering tool for flight research projects has been developed through the use of 
a workgroup database. Capabilities are implemented for typical flight research systems engineering needs 
in document library, configuration control, hazard analysis, hardware database, requirements 
management, action item tracking, project team information, and technical performance metrics. 
Repetitive tasks are automated to reduce workload and errors. Current data and documents are instantly 
available online and can be worked on collaboratively. Existing forms and conventional processes are 
used, rather than inventing or changing processes to fit the tool. An integrated tool set offers advantages 
by automatically cross-referencing data, minimizing redundant data entry, and reducing the number of 
programs that must be learned. With a simplified approach, significant improvements are attained over 
existing capabilities for minimal cost. By using a workgroup-level database platform, personnel most 
directly involved in the project can develop, modify, and maintain the system, thereby saving time and 
money. As a pilot project, the system has been used to support an in-house flight experiment. Options are 
proposed for developing and deploying this type of tool on a more extensive basis. 

NOMENCLATURE 


CBE 

current best estimate 

CCB 

configuration control board 

CCR 

configuration control request 

Cl 

configuration item 

DR 

discrepancy report 

D-REX 

Ducted Rocket Experiment 

eSE 

Electronic Systems Engineering 

GUI 

graphical user interface 

HR 

hazard report 

PFTF 

Propulsion Flight Test Fixture 

STR 

system test report 


INTRODUCTION 


Systems engineering is defined as a robust approach to the design, creation, and operation of 
systems (ref. 1). Systems engineering is important for the successful execution of flight research projects, 
which characteristically have complex interdependencies between elements and subsystems. Typical 
systems engineering tasks in a flight research project include configuration control, document 
management, discrepancy tracking, hazard management, requirements management, verification and 
validation, action item tracking, and technical performance metrics. 



Software tools often are used to facilitate systems engineering tasks, and these tools provide potential 
benefits. For example, current project data and documents can be instantly accessed online, and repetitive 
tasks can be automated, resulting in error reduction and improved situational awareness. A net savings of 
time and money could be realized, even considering the upfront investment to implement the software 
tools. 

In flight research, however, each project is technically and programmatically unique, so a standard set 
of software tools is often unavailable or not applicable. If enterprise-level software packages were 
implemented, the life cycle cost for procurement, development, training, and administration would be 
high and burdensome for a relatively small organization like the NASA Dryden Flight Research Center 
(Edwards, California). Furthermore, NASA Dryden frequently is a partner in a project led by another 
organization, in which case the lead organization often mandates usage of its set of tools. NASA Dryden 
then becomes a client user of those software packages, which is the proper and economical approach, but 
any sizable investments in in-house tools are not recouped. 

Most of these systems engineering tools are fundamentally databases. They generically store and 
organize information and present it in various ways. Many systems engineering tools are built on one of 
the well-known commercial or standard database applications. 

Coincidentally, a commercial off-the-shelf workgroup database is already deployed center-wide at 
NASA Dryden (ref. 2). It is a relational database that is accessible over the network, scalable to over 
100 users, and available for both PC and Mac platforms. As a workgroup-level tool, it can be 
programmed easily and quickly, allowing the people performing the work to develop the solution. The 
life cycle cost of solutions by means of this software is estimated to be one-fifth that of an 
enterprise-level database. In this case because the database is already procured and deployed, the cost 
savings may be even greater. 

The implementation of an Electronic Systems Engineering (eSE) tool is proposed for in-house and 
NASA Dryden-led projects that use this platform database. Although this database is considered a 
workgroup-level tool, cases in which it has been used in some major aerospace applications are described 
on the vendor’s Web site. At NASA Dryden, it is used for work orders, aircraft scheduling, inspection, 
waivers, aircraft directives, operational training, flight logs, and flight project risk management. The 
database vendor's Web site indicates that the database has been used at some other major aerospace 
organizations for test tracking, maintenance documentation, parts tracking, document archiving, and 
instrument calibration data. 

Figure 1 shows the overall setup of the eSE modules. An integrated set of modules is potentially more 
advantageous than separate products, because data are automatically cross-referenced between modules, 
and a common user interface and administration are possible. The project can still select the appropriate 
modules, depending on utility. Only the most expensive and complex enterprise-level products provide 
an integrated capability covering various systems engineering functions. 

The eSE can be accessed online over the intranet from each user’s workstation. When a projector and 
networked computer are used during meetings or presentations, data can be displayed and collaboratively 
worked on in real time. Established institutional processes are implemented. Processes are owned by the 
current process owners, and are not changed to fit the tool. No redundant capability is generated for areas 
in which appropriate software tools already are available, such as finance, scheduling, project workflow, 
and work orders. A simplified approach is taken to provide maximum benefits for minimal cost. The 
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system can be easily customized to meet unique project needs. The present capability of this tool is for 
nonsensitive in-house projects. Some essential features of the system are as follows: 

• Online document viewing and editing capability 

• User identification and password access control 

• Privilege control based on user access level and document status 

• Electronic signatures 

• Electronic attachments 

• Automatic summary data generation 

Table 1 shows some of the benefits of using the eSE system. 


Table 1. Benefits of using the eSE system. 


Task 

Old way 

New way 

Generate a hazard 
action matrix 

Page through all the hazard reports and manually 
tally counts. Repeat periodically to keep current. 

Push a button. 
Repeat to update. 

View or submit 
configuration control 
forms 

Walk to another building to view records or 
submit a hard copy. Data entry personnel enters 
data into system. 

View, edit, and submit 
forms online. 

Obtain a project 
document 

Ask author or someone else to E-mail the 
document and hope that it is the current version. 

Download current 
document from server. 

Track action items 

Distribute a spreadsheet through E-mail. 
Manually incorporate inputs and updates 

View and edit action 
items online. 

Find hardware data 

Search through large binders. 

Navigate to data 
through links. 

Generate a verification 
requirements matrix 

Copy and paste requirements document text. 
Manually update if document changes. 

Push a button. 

Updates are automatic. 


*Not used in pilot project. 


Development of the eSE, including coding, debugging, testing and this documentation was 
accomplished in approximately 1000 person-hours. The eSE was demonstrated and further developed on 
a pilot project, the Ducted Rocket Experiment (D-REX), on the F-15B (McDonnell Douglas Corporation, 
St. Louis, Missouri) Propulsion Flight Test Fixture (PFTF) (fig. 2). The PFTF is a pod carried under an 
F-15B aircraft to provide the capability to test large scale airbreathing propulsion engines. In D-REX, a 
simple flowpath and systems were planned to be used to obtain ducted rocket flight data, gain operational 
experience, and demonstrate hot fire capability (ref. 3). The D-REX flight hardware was developed 
in-house at NASA Dryden by approximately 10 participants. 
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USAGE 


This section describes the features and usage of the eSE. Like other software driven by a graphical 
user interface (GUI), it is intended to be usable without the need for a detailed manual. 

Access Control 

Access to the system is controlled through the use of a small access file that is distributed to all the 
users. When the file is opened, the user name and password is requested. Both fields can be left blank for 
read-only access. The database is opened at one of the four access levels assigned to the user: 
administrator, project, user, and public. Access control is currently provided, but more rigorous security 
measures, such as encryption, are not. 

Administrator 

The administrator access level allows complete control of the database, including programming and 
defining layouts. Access at this level requires an additional password. 

Project 

The project access level is intended for use by project-level personnel such as the project manager, 
chief engineer, operations engineer, systems safety, and systems engineering. It allows nearly complete 
control of the database contents, except in certain cases to preserve integrity. For example, records that 
have been signed off cannot be deleted. 

User 

The user access level is assigned to the majority of users. It allows the viewing and editing of the 
database contents, except when a lockout is imposed under certain conditions. For example, records that 
have been signed off cannot be modified. 

Public 

The public access level allows read-only access without a password. It can be disabled if desired. 

Document Library 

The document library contains the product data for each project in various formats. The interface is 
like other typical GUI file managers but contains additional features for product data management. For 
example, metadata, such as author and revisions, are stored and can be searched on. Revision histories are 
maintained. Electronic signatures can be used to approve documents. Documents can be checked out for 
editing, and only the users who check the documents out can check them back in. This way, multiple 
users are not inadvertently editing the same document. Figure 3 shows an example of a document library. 
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Documents can be accessed from other modules by means of links. A document must be filed in the 
document library before it can be attached to a record elsewhere in the database. 

The database actually manages only the metadata of the documents and provides links to the 
document files through uniform resource locators (URLs). An advantage of this approach is that a failure 
or malfunction of the database cannot compromise the document files. Documents are uploaded to the 
server by simply copying the file to the server directory. 

Configuration Control 

Tracking the configuration, discrepancies, and tests of an entire flight vehicle is a complex task. At 
NASA Dryden, a configuration control board (CCB) manages this process. The configuration control 
module, however, was not used in the pilot project. Processes and applicable forms, such as configuration 
control requests (CCRs), discrepancy reports (DRs), and system test reports (STRs) are implemented in 
the eSE. Figure 4 shows an example of the CCB DR form. The CCR and STR forms have similar 
formats. Links allow easy navigation between related forms. A history of actions is automatically 
compiled on a form. Supporting documents can be electronically attached. Summary tables can be 
automatically generated. Interlocks help prevent unauthorized alteration of data depending on the phase 
in the process. Signature blocks are locked out depending on access level. A list of configuration items 
(CIs) is maintained. 

The CCB automation process begins with an online user request for CCB actions. The CCB agenda is 
automatically generated from the requests (figure 5 provides an example). At the CCB meeting, these 
requests are reviewed and acted upon in real time. Actions are recorded in the CCB action field, and the 
date field is filled in. The CCB meeting minutes are automatically generated from the data that was 
entered. 


Hazard Management 

Managing hazards is a significant effort in flight projects. At NASA Dryden, standard hazard report 
(HR) forms and processes are implemented. Figure 6 shows an example of an HR form. As with the 
configuration control forms, links, form histories, attachments, summary tables, interlocks, and electronic 
signatures are implemented. An HR can be automatically generated using data from hazard analyses. To 
support hazard analyses, three techniques are incorporated (ref. 4): preliminary hazard analysis (PHA), 
failure modes and effects analysis (FMEA), and fault tree analysis (FTA). 

Preliminary Hazard Analysis (PHA) 

A PHA is a structured way to explore potential hazards early in the program. It is implemented as a 
simple table. 

Failure Modes and Effects Analysis (FMEA) 

This technique is a rigorous analysis of potential single point failures. It also is implemented as a 
table but has links to the component database to aid in data entry and help ensure consistency. To help 
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interpret the large volume of data, the list can be sorted by component, hazard rating, or mission phase by 
simply clicking on the header. 


Fault Tree Analysis (FTA) 

This analysis explores potential causes and mitigations for an undesirable top level event. A simple 
fault tree can be constructed and manipulated using a GUI, although the format is horizontal because of 
program limitations. Probabilities of events can be calculated. In FTA, cut-sets are used to evaluate 
potential causes, but this feature has not yet been implemented. 


Hardware Database 


Tracking flight hardware and its development involves organizing and managing large quantities of 
data. As shown in figure 7, this module consists of five databases linked together: component types, unit 
components, vehicle components, subsystems, and instrumentation. These five linked databases allow 
the interconnection of relevant information. 


Component Types 


Component types are the particular hardware designs. Data associated with component types include 
flight qualification requirements, flight qualification approach, drawings, documents, price, heritage, and 
design life. Qualification matrices can be automatically generated from the data provided. Links are 
provided to vehicle components of this type and inventory of individual components. Fields can easily be 
added to meet specific project needs. For example, in the pilot project, component materials were tracked 
to help ensure compatibility with propellants. Figure 8 shows an example of a component type data sheet. 

Unit Components 

Unit components are the actual physical pieces of hardware. Data associated with unit components 
include serial number, acceptance testing, usage and cycle history, anomalous events, and associated 
documentation. Links are provided to corresponding component types and vehicle components. The 
official records typically are kept in the aircraft workbook, but an electronic database expands on that 
information and allows online access. 

Vehicle Components 

Vehicle components are the designations given to parts in the vehicle. For each vehicle component, a 
component type is associated with it, and a unit component can be installed in it. This information must 
be configuration controlled and can be used to support a physical configuration audit of the vehicle. 
Links are provided to corresponding component types and unit components. Official records for parts 
removals and installations also are kept in the aircraft workbook. 
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Subsystems 

Subsystems organize the physical project elements into logical sections. These sections should 
include, in addition to vehicle subsystems, other essentials such as ground service equipment and the test 
range. Interfaces between subsystems can be defined and associated with interface control documents 
(ICDs). 

Instrumentation 

Instrumentation is the table of data related to instrumentation parameters and traditionally is 
maintained by the instrumentation engineer. The data can be edited and viewed online, with links to 
corresponding vehicle components, component types, and unit components. 

Requirements 

Project requirements traditionally are managed using documents and spreadsheets. This management 
method was considered adequate for D-REX, which was a relatively small in-house project. For more 
complex projects, however, a data-centric approach may provide significant benefits by reducing 
repetitive tasks and inconsistency errors, especially for changing, tracing, and verifying requirements. 
Excellent enterprise-level tools exist for these functions, but they may not be available or affordable in 
some cases. 

In this module, the requirements outline can be constructed and manipulated with a GUI. More than 
one requirements set can be defined. Requirements between various sets can be linked, a task that is very 
tedious to perform manually. Verification requirements matrices and requirements documents can be 
automatically generated from the database. Figure 9 shows an example of a requirements document 
generated from the database. For tracking purposes, each requirement is assigned a unique five-digit 
identification number that never changes, regardless of its line item number in the requirements 
document. 


Action Items 

Action items commonly are used to track project activities. Through the use of this module, actions 
can be requested, viewed, and responded to online in real time. The status of each item (open, closed, 
late) is automatically tracked. Electronic signatures are used to submit and accept closing actions. A 
“nag” button can be used to remind action recipients (through E-mail) of overdue items or any updates 
requiring attention. This module can be used to support various project reviews and help ensure that 
request for information (RFI) items are tracked, addressed, and closed. Figure 10 shows an example of an 
action items list. 


Team Information 

Most projects maintain a team roster, organization chart, and project- specific training records. This 
module is not intended to replace actual directory services or personnel records. Training class rosters 
and each individual’s class attendance can be viewed. One or all personnel can be contacted by E-mail at 
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the push of a button. A simple organizational chart can be generated in a horizontal outline format. This 
module also is used to support the access control and electronic signature features of the software. 

Metrics 

Tracking technical performance metrics is a common practice for measuring the status and progress 
of a project. In this module, current best estimates (CBEs), allowable limits, and margins of metrics can 
be tracked. Time histories of metrics are presented both graphically in a plot and in tabular form. Data 
can be imported and exported in common text formats. The plot is simply an embedded object from a 
spreadsheet and graphing program, thus the format can be freely changed to the extent that the graphing 
program allows. Figure 11 shows an example of a technical performance metric. 

Data Import and Export 

Features are implemented for users to export several standard reports to tabulated text files. In 
addition, the administrator can import and export any combination of data in a variety of formats. The 
platform database program supports the importation of several text and spreadsheet formats, and the 
exportation of text, spreadsheet, and hypertext markup language (HTMF) formats. 

DISCUSSION 

The benefits of an online systems engineering tool, the eSE, have been demonstrated. The eSE 
facilitated in-house development of the D-REX project. Part of the challenge being addressed is to 
organize and provide easy access to a large volume of information. Ideas for improvements and features 
suggested by project members have been implemented. “Bugs” and other issues discovered by users have 
been corrected. 

The eSE is fairly stable and usable in its present form and could be made available to other projects. It 
can also be easily modified for specific project needs. Currently eSE is probably most suitable for 
in-house projects. The database administrator should be fa mi liar with the platform database but does not 
need to be a computer professional. 

Some additional features and improvements are suggested. For example, E-mail notification could be 
provided for certain events. The system could be easily interfaced with other tools at the center that use 
the same platform database, as appropriate. Other programs could be used to access the database by 
means of standard interfaces. 

The benefits of complete integration across the project have been demonstrated; however, if a system 
of this type is to be more widely deployed, it probably would be separated into several process-centric 
products, corresponding to an existing organizational structure. These products may include 
configuration control, safety, and projects (documents, actions, metrics, requirements, and hardware). 
Notionally, the configuration control and safety modules would have a center-wide server, whereas each 
project would have its own project module server that could be customized. This approach would 
simplify systems maintenance, facilitate cross-project data sharing, and allow customization in 
project- specific areas. In this case, eSE should be migrated to the newly released version of the platform 
database software. The new version has significant new features, such as an improved Web server, 
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built-in user identification and password security, and extensive import and export capabilities. The 
database would then reside on a server and could be accessed from any workstation through the use of a 
Web browser. 


CONCLUDING REMARKS 

An online systems engineering tool for flight research projects was developed through the use of a 
workgroup database. The principal observations are as follows: 

• The features implemented include document library, configuration control, hazard analysis, 
hardware database, requirements management, action item tracking, project team data, and 
technical performance metrics. Existing processes and forms are implemented, rather than 
inventing or changing processes to fit the tool. 

• The life cycle cost of this type of implementation is approximately one-fifth that of 
enterprise-level systems. 

• By using a workgroup database platform, personnel most directly involved in the project can 
develop, modify, and maintain the system. 

• The system has been demonstrated and developed on a pilot project, the F-15B Propulsion Flight 
Test Fixture Ducted Rocket Experiment. 

• The system could be made available to other projects. 

• An integrated project tool set offers numerous advantages. If the system is to be widely deployed, 
however, it probably would be separated into several process-centric products and migrated to the 
newest version of the platform database. 
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Figure 1. Overall setup of the Electronic Systems Engineering (eSE) modules. 



Figure 2. F-15B aircraft in flight with Propulsion Flight Test Fixture. 
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ooooooooooooooooooo 


HOME ] \ NEW DOCUMENT ) NEW FOLDER ) MOVE ) 

FIND J DELETE J [ VIEW TABLE ) 

PFTF-RBCC 

DOCUMENT LIBRARY 


TOP 


|°~| briefings 

Q CDR rocket 
|°~| components 

|°~| Fike burst disks 

Fike ASME code and rupture disks 
[^1 Fike Rupture Disk Poly-SD series 
f-| Kulite 

Q Kulite BM-1 100 BME- 1100 spec sheet 
|°~| Lincoln tank 

Lincoln tank cleaning pics 
n manual valve 

Q boss and installations - air connection 

Q bosses, fluid connection, internal straight thread 

valve, air, high pressure charging, 5000 psi 

Q valve, aircraft, pneumatic, high-pressure charging 

m Marotta CVM608 

acceptance test procedure, check valves 

Q qualification test procedure, CVM608-001-5 

Pi Qualification test report, free flow check valve, model CVM608-001-5 
LJ 040305 

Figure 3. Document library example. 
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National Aeronautics and 
Space Administration 

Dryden Flight Research Center 


Discrepancy Report (DR) 

Software/Hardware 
Control Management 


Project 

PFTF-RBCC 

Originator/Org: 
Banks, George 

Site: 

airplane 

Date &Time Of Dkc.: 
1/2/1901 

Dr No. 
1 

El VEHICLE 

□ CONTROL ROOM 

□ SIMULATION 

□ OTHER: 

A/C Facility 

844 

A/C S/N: 

Fit No Or Test No 

Criticality: 

Assigned To: 

Part Name: 

Part No.: 

Serial No.: 

Cl No.: (system) 

Ini. Ccb Review Date: 

TITLE: 

mouse in aircraft 


Decrepancy: 

mouse found in experimental aircraft 


Signature: 

tom 


Date: 

6/18/2003 


Disposition: 

access panel open overnight 


Signature: 

tom 


Date: 

6/18/2003 


Required Fix: (work-around) 

keep cat 


Signature: 

tom 


Date: 

6/18/2003 


Closing Action: 

cat obtained and trained 


Work Order: 

PCN NO.: 

CCR NO.: 

♦ 1 CLOSED # 

V * 


STR NO.: 

123 # 

* * 



Tested By: 

brad 


Date: 

6/18/2003 


Witnessed By: 

brandon 


Date: 

6/18/2003 


CCB official 

Me 


Date: 

6/18/2003 


CCB Official: 

Kevin Long 


Date: 

10/15/2003 


DFRC 9 (08/01) 

COMPUTER DATABASE. PRINTED DOCUMENTS ARE FOR REFERENCE ONLY 


Attachment (tile name): 


Cview) 


Cockpit Panel Rev. 1.0. ppt 


Figure 4. Configuration control board (CCB) discrepancy report (DR) form example. 
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| RETURN j | NEW MEETING ) 


PFTF-RBCC CCB AGENDA 12/18/2003 


ATTENDEES 

REQUIRED POSITION NAME 


E 

project manager 

George Banks 

IEI 

chief engineer 

Rodney Chin 

□ 


Patrick MacKenzie 

□ 


Sean Michaels 

□ 


Daniel Kohnen 

□ 



□ 



□ 



□ 



□ 



□ 



□ 




AGENDA ITEMS 

ITEM REQUEST CCB ACTION 


CCR 1 

REQUESTOR & DATE 
Kevin Long 

4/13/2004 

close this CCR 

CCR cannot be closed yet 

goto! done ) 

DR 1 

REQUESTOR & DATE 
Kevin Long 

4/13/2004 

modify DR to include new text 

DR modified as requested 

GOTOf DONE 1 

STR 123 

REQUESTOR & DATE 
Hanz Denney 

10/10/2003 

open this STR 

STR opened 

GOTO)' DONE ) 


040307 


Figure 5. Configuration control board (CCB) agenda example. 
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National Aeronautics and 
Space Administration 

Dryden Flight Research Center 


HAZARD REPORT (HR) 


PROJECT 

ORIGINATOR70RG.: 

TITLE 

SITE 

DATE 

HR NO. 

PFTF-RBCC 

Chin, Rodney / RA 

Loss of Control 

DFRC 

12/5/2002 

DRex 05 


Information source: 

H DESIGN REVIEW 
K HAZARD ANALYSIS 

□ FIELD REPORT 

□ TEST 

□ DISREPANCY RPT 


Location: 

□ SAFETY STUDY 
K VEHICLE 

□ CONTROL ROOM 

□ SIMULATION 

□ OTHER 


WC FACILITY 
F-15B 


A/C S/N: 

836 


CATEGORY/PROB.: 

IE 


SYSTEM NAME: 

PFTF / DRex 


Cl NO.: (SYSTEM) 


ASSIGNED TO: 

Chin, Rodney 


RELATED 

DR'S: 


HAZARD ANALYSIS OR SAFETY STUDY NAME: 
Preliminary Hazard Analysis 


HAZARD DESCRIPTION AND JUSTIFICATION FOR CATEGORY / PROBILITY RATING: 

Loss of control due to the experiment could result in loss of aircraft and/or life (Cat 1). The PFTF / DRex configuration 
is predicted to cause a small reduction in open-loop directional stability and dihedral effect compared to a baseline 
F-15B. An extreme misprediction of the experiment configuration S&C characteristics would be required for the 
experiment to the cause the aircraft to go out of control during a CAS failure. This is considered improbable (Prob F). 
SIG.: DATE: 


CAUSE 

1) Yaw /Roll CAS failure while at high supersonic Mach numbers and an extreme misprediction of the reduced 
open-loop Cnp and Cl|i due to the presence of the PFTF / DRex experiment. 

2) Rocket thrust 


SIG.: 


DATE: 


HAZARD EFFECTS: 

1) Structural damage or loss of F-1 5B or chase aircraft and possible resulting loss of life 

2) Loss of life at ground impact. 


SIG.: DATE: 


CONTROL BOARD ACTION 

□ OPEN 

RECOMMENDED ACTION 


□ ACCEPTED (TO RISKUST) 




PROJECT MANAGER 

DATE: 

PROJECT MANAGER 

DATE: 

HAZARD RISK REDUCTION ACTION 


Mitigation of this hazard by Design and Previous Flight Test Experience: 

1) Flight tests of the similar sized and shaped AFTF and PFTF Cone Drag Experiments with the CAS off have 
shown acceptable handling qualities with the CAS off at speeds up to Mach 1.8 and no pilot concerns at speeds 
greater than 1.8. 

2) It has been shown in the sim that the maximum expected DRex experiment thrust of 1100 lb will not result in loss 

of oontrol since it is in the axial direction nor will it cause any handling qualities degradation ( sim study still to be 
SIG.: DATE: 


CLOSING ACTIONS 


PROJECT MANAGER: 
DATE: 


PROJECT PILOT: 
DATE: 


HR FORM (1/96) 


COMPUTER DATABASE. PRINTED DOCUMENTS ARE FOR REFERENCEONLY 


ATTACHMENT (FILENAME): 

| 1 □ DISAPPROVE 

040308 


Figure 6. Hazard report (HR) example. 
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HOME ) 


f HELP ) 



040309 


Figure 7. Hardware database. 
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PFTF-RBCC 


COMPONENT TYPE DATA 


4 / 9/2004 


MFR. 
MODEL 
MFR P/N 
DESCRIP. 



VEHICLE P/N 
MV-FUP-02 
MV-OXP-02 


INVENTORY S/N 
001 
002 

003 

004 

005 

006 


orQTY: 



REQUIREMENT 

QUALIFICATION 

STATUS 

ALTITUDE 



n/a 

THERMAL 

•65F to +160F 

cold temps during blowdown 

test per requirement 

TBD 

VIBRATION 

DCP-O-018 random vibe curve A 
(8.0 Grms), 3 axes, 20 min/axis, 
protoflight 

test per requirement 

TBD 

SHOCK 



n/a 

EMC 



n/a 

PRESSURE / 
LEAK 

burst test 7500 psi 

external leak bubble tight at 3000 

psi 

internal leak ?? sees at 3000 psi 

bubble tight (by immersion) at 5000 psi 
burst to 1 2500 psi 

ok 

LIFE 

??? open-close cycles 

1 00 open-dose cycles to 55+/- in-lb torque 

(good for 25 cycles?) 

longer life based on extensive heritage? 

TBD 

FUNCTIONAL 

OTHER 


flow at least 80 Ipm gas at 5000 psi 
audible pressure warning over 50 psi 

n/a 



n/a 

ACCEPTANCE 

proof test 4500 psi 


PRESSURES (psi) 

oper 

MEOP 

proof 

burst 


5000 



FITTINGS 
type size 

see dwg 



DOCUMENTS 


MIL-PRF-6164F.pdf 

MS33649.PDF 

MS33651.PDF 


HERITAGE 


REMARKS 


consider M 61 64-1 2 for thermal qual and 
higher cycle life. 


MASS (Ibm) | 
max 

LIFE 


units 


□ LIFE LIMITED 


PRICES [70 
Vendor 


WORKING FLUIDS 
|GN2 | | 

WETTED MAT'LS 


M IL-G-4343 
MIL-H-6083 
MIL-P-83461/1 
metal? 


COMPUTER DATABASE. PRINTED COPIES ARE FOR REFERENCE ONLY 


Figure 8. Component type data example. 
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PFTF-RBCC 

Requirements for propulsion subsystem 

1 fuel system 

The fuel system will feed JP-7 to the engine 



Combus tor/ 
Nozzle 


1.1 fuel system performance 

The fuel system shall deliver 0.5 Ibm/sec fuel at 500 psi at the engine 
interface. The test duration shall be 10 seconds, requiring a useful fuel 
load of 5 Ibm 

2 oxidizer system 

The oxidizer system will feed 90% H202 to the engine 

2.1 oxidizer material compatibility 

Materials used in the oxidizer system shall be class I or II compatible with 
H202 

2.2 oxidizer system performance 

The oxidizer system shall deliver 0.5 Ibm/sec of oxidizer at 500 psi at the 
engine interface. The test duration shall be 10 seconds, requiring a useful 
fuel load of 5 Ibm 

3 rocket engine 


Figure 9. Requirements document example. 


4 / 13/2004 


040311 
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HOME 1 f EXPORT 1 



PFTF-RBCC 


ACTIONS 




4/9/2004 


ID 

TITLE 

REQUESTOR 

DATE REQUEST 
ASSIGNEE (event) 

DATE 

DUE 

DATE 

CLOSE 

STATUS 


3U 

ask hrenrex 

Long, Kevin 

Mactvenzie, rairicK 



Tinwznuj 

ULUbbU 

□ 

31 

ask Lincoln Composites 

Long, Kevin 

MacKenzie, Patrick 

6/26/2003 



OPEN 

□ 

32 

ask manual valve vendor or 
user 

Long, Kevin 

Anderson, Greg 

6/26/2003 


10/16/2003 

CLOSED 

Q 

33 

instrument quals 

Long, Kevin 

Michaels, Sean 

6/26/2003 


1/13/2004 

CLOSED 

□ 

34 

write ORD 

MacKenzie, Patrick 

MacKenzie, Patrick 

7/1/2003 



OPEN 

O 

35 

write requirements doc 

Anderson, Greg 

Long, Kevin 

7/1/2003 



PENDING 

O 

36 

conversation with GK 

MacKenzie, Patrick 

MacKenzie, Patrick 

6/28/2003 


6/26/2003 

CLOSED 

Q 

37 

CoDR RFAs Mizukami 

Long, Kevin 

MacKenzie, Patrick 

3/5/2003 

CoDR 


4/1/2003 

CLOSED 

Q 

38 

clean tanks and valves 

MacKenzie, Patrick 

Long, Kevin 

8/19/2003 


10/1/2003 

CLOSED 

Q 

40 

component vibe tests 

Long, Kevin 

Kohnen, Daniel 

10/14/2003 

2/15/2004 


OPEN 


040312 


Figure 10. Action items list example. 


HOME ] ( NEW METRIC ] 

PFTF-RBCC 

METRICS 


METRIC: 

sample metric 

□ LOCK 



1/1/2003 3/2/2003 5/1/2003 6/30/2003 8/29/2003 10/28/2003 12/27/2003 


CBE 

lo 

hi 


double click on plot to view/edit data 04031 3 

Figure 1 1 . Technical performance metric example. 
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